Long Term Evolution (LTE) includes a discontinuous reception (DRX) mode to conserve the battery of a terminal device. When DRX mode is configured in a terminal device, the terminal device is able to turn its receiver off and enter a low-power state, waking for defined (periodic) phases to listen for scheduling messages or other wireless communications. For example, when the terminal device is in a DRX sleep state, it does not need to listen on the physical downlink control channel (PDCCH). When the terminal device is in the DRX active state, it must normally listen on the PDCCH to wait for potential scheduling requests from the network (e.g. from the eNodeB).
According to the 3rd Generation Partnership Project (3GPP) media access control (MAC) standard for LTE (Technical Specification Group 36.321, version 12.9.0), the terminal device is in the DRX active state when any of the conditions specified in section 5.7 is true, that is to say:
1 DRX parameters are not configured; or
2 DRX parameters are configured and                2.1 drx-Inactivity Timer is running; or        2.2 drx-Retransmission Timer is running; or        2.3 mac-ContentionResolutionTimer is running; or        2.4 a Scheduling Request sent on the physical uplink control channel (PUCCH) is pending; or        2.5 an uplink grant for a pending hybrid automatic repeat request (HARQ) retransmission can occur and there is data in the corresponding HARQ buffer; or        2.6 a PDCCH indicating a new transmission addressed to the C-RNTI of the terminal device has not been received after successful reception of a Random Access Response for the explicitly signaled preamble (only applicable to terminal devices in RRC_CONNECTED).        
If none of these conditions is true, then the terminal device is in the DRX sleep state (i.e. its receiver is turned off).
A terminal device in RRC_CONNECTED state and which has been configured with the DRX function can be configured with both a long DRX cycle and a short DRX cycle. The intention with the long DRX cycle is that the terminal device should be able to sleep for a long time and wake up only periodically to listen for any new scheduling requests. The intention with the short DRX cycle is that the terminal device should be awake more frequently than in the long DRX cycle to listen for any scheduling requests. Those time periods when the terminal device is awake to listen for scheduling requests are called OnDuration periods, and are configured for a certain time duration.
When the terminal device is scheduled, an inactivity timer called drx-InactivityTimer is started and while this timer is running the terminal device is awake to listen for any scheduling requests. When the drx-InactivityTimer expires, the terminal device will go to short DRX sleep, if configured, otherwise the terminal device will go to long DRX sleep.
If the terminal device has not been scheduled for a configured number of short DRX cycles the terminal device will go to long DRX sleep.
The problem with the existing solution for DRX is that, to ensure high throughput data transfer when sending/receiving large data volumes, it is important to use a rather long drx-InactivityTimer. This is needed for mainly two reasons: one is that due to transmission control protocol (TCP) flow control, there may not always be data in the buffer to send/receive, but new data can come at any time; and a second reason is that the load in the radio network node (e.g. the eNodeB) may vary significantly and the eNodeB may not always be able to schedule a terminal device for a number of subframes due to high load. However, when it can schedule the terminal device, it is important that the terminal device is in DRX active time to receive the scheduling messages.
However, using a large value for the drx-InactivityTimer (such as 200 ms) will in many cases cause the terminal device to be awake for much longer than necessary. For many short traffic flows there is no need for the terminal device to be kept awake for this long time.
For example, when voice over LTE (VoLTE) traffic is ongoing for the terminal device, in many cases it may be advantageous to configure a short drx-InactivityTimer to allow the terminal device some short sleep period between sending/receiving the speech frames. However, if a medium or large data packet needs to be transmitted or received during this speech call, lower throughput will be achieved for the data transfer because of the small value of the drx-InactivityTimer.
Reconfiguring the length of the drx-InactivityTimer when needed using the RRC protocol is not always optimal because it is difficult to know when reconfiguration should be done, and it is costly in signaling resources in the radio network node and in the radio interface. In the worst cases, a data burst may end shortly after a reconfiguration from a short to a long drx-InactivityTimer, or a large data burst may start shortly after a reconfiguration from a long to a short drx-InactivityTimer.